home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000016_owner-urn-ietf _Mon Nov 4 05:51:04 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA27406 for urn-ietf-out; Mon, 4 Nov 1996 05:51:04 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA27401 for <urn-ietf@services.bunyip.com>; Mon, 4 Nov 1996 05:51:02 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA21183  (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 05:51:00 -0500
  5. Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
  6.           id <00908-0@josef.ifi.unizh.ch>; Mon, 4 Nov 1996 11:50:37 +0100
  7. Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax 
  8.          draft)
  9. To: jayhawk@ds.internic.net
  10. Date: Mon, 4 Nov 1996 11:50:36 +0100 (MET)
  11. Cc: urn-ietf@bunyip.com
  12. In-Reply-To: <9611011512.AA05839@mocha.bunyip.com> from "Ryan Moats" at Nov 1, 96 09:12:22 am
  13. Mime-Version: 1.0
  14. Content-Type: text/plain; charset=US-ASCII
  15. Content-Transfer-Encoding: 7bit
  16. Content-Length: 1322
  17. From: Martin J Duerst <mduerst@ifi.unizh.ch>
  18. Message-Id: <"josef.ifi..324:04.10.96.10.50.51"@ifi.unizh.ch>
  19. Sender: owner-urn-ietf@services.bunyip.com
  20. Precedence: bulk
  21. Reply-To: Martin J Duerst <mduerst@ifi.unizh.ch>
  22. Errors-To: owner-urn-ietf@bunyip.com
  23.  
  24. Ryan Moats wrote:
  25.  
  26. >>Now for UTF-8, things are quite different. 8-bit bytes will
  27. >>on many occasions be escaped because it may be difficult to
  28. >>represent them otherwise. Having some character beyond ASCII
  29. >>represented with %HH (usually %HH%HH or %HH%HH%HH) can in no
  30. >>way imply that this is a special character.
  31. >>This means that any tools dealing with URNs in general will
  32. >>have no clue about where to keep the escaping, and where
  33. >>to remove it. A very exact knowledge of each NSS syntax
  34. >>would be needed.
  35. >
  36. >My brain hurts, but I think I finally understand the issue.
  37.  
  38. Sorry for my long explanations.
  39.  
  40. >Allow me to restate it to see if I'm right:
  41. >
  42. >The problem you are talking about arrises if the reserved character has
  43. >a UTF-8 representation of more than 1 octet.  Then, if we use %encoding
  44. >to represent the character in a literal use, there is no way of determining
  45. >from the URN whether the character is being used as a literal character
  46. >or not. 
  47.  
  48. Exactly.
  49.  
  50. >I'll save a discussion of potential solution directions to this until I'm sure
  51. >I understand the issue.
  52.  
  53. I have already mentionned two possibilities:
  54.  
  55. - Specify that protocols may only reserve 1-octet UTF-8 characters
  56.     (i.e. ASCII).
  57. - Specify that protocols have to define their own escaping mechanisms
  58.     for things beyond ASCII.
  59.  
  60. Regards,    Martin.